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Resumen. En este trabajo se plantean los principales conceptos de la 
simulación de sistemas operativos y se presenta como caso de estudio el 
desarrollo de un simulador de un sistema operativo mínimo. 


Palabras clave: sistemas operativos, simulación. 


1. La simulación de sistemas operativos 


La simulación, es un método científico no obstructivo de estudio que involucra 
experimentos con un modelo en lugar de la porción de la realidad que el modelo 
representa. A pesar de que mucha de la información provista por la simulación esté ya 
contenida en el modelo, la simulación es útil cuando gran cantidad de partes 
interactúan con muchas rutas que necesitan ser rastreadas simultáneamente, lo que 
requiere realizar una gran cantidad de iteraciones para aproximarse a los resultados. El 
poder generar una historia sintética de procesos dinámicos y poder manipular los 
eventos y condiciones del modelo es lo que hacen de la simulación una técnica idónea 
para el diseño de sistemas operativos, como se verá más adelante. Aún cuando se 
considera que una implantación real es la única forma de comprobar la eficacia de un 
diseño, en el caso de los sistemas operativos, la simulación ha sido aplicada por varios 
grupos de trabajo. Aún cuando Silberschatz menciona en su tercera edición de 
“Conceptos de sistemas operativos” (pp. 126) que "las simulaciones pueden ser muy 
caras, al requerir horas de tiempo de computo, y más cuando se desea mucho detalle", 
es claro que con el poder de las actuales computadoras, y lo que está por venir, las 
consideraciones de recursos pueden quedar en un segundo plano. 


2. Simuladores de sistemas operativos 


Entre los principales simuladores de sistemas operativos destacan [1] [2][3][4][5]: 


a. NachOS (Berkeley). Nachos es un sistema instruccional para la enseñanza de cursos 
de sistemas operativos. La distribución de Nachos contiene el código base para un SO 
operacional y un simulador de una computadora genérica. 


b. SimOS. Simula el hardware de una computadora con detalle suficiente para cargar y 
ejecutar sistemas operativos comerciales, además de proveer un ambiente completo de 
análisis de ejecución y carga de trabajo. 
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hardware simulado, el cual esta basado en la máquina P (P-Machine), un sistema de 
computo hipotético simple. Incluye un compilador de C/C++ que genera P-Code que 
puede ejecutar la máquina P. 


d. SOS (Simple Operating System Simulator). El libro "Operating Systems: A Design- 
Oriented Approach" (Charles Crowley, Irwin, 1997) contiene el código (C++) para un 
sencillo sistema operativo llamado SOS, el cual se ejecuta en una plataforma de 
hardware llamada CRA-1, la cual es una máquina RISC simple. 


e. Flux OSKit (Utah). Es una plataforma con un conjunto de 34 librerías de 
componentes que facilita la creación de un nuevo sistema operativo portando un SO 
existente a otra plataforma (p.ej. x86), ampliar el soporte de dispositivos, formatos de 
sistemas de archivos, formatos ejecutables, o servicios de red; así como construir 
programas relacionados, como cargadores o servidores montados sobre un microkernel. 


f. Palm OS Simulator. Es el simulador del Palm OS 5.0; no es una emulación del 
hardware como el PalmOS Emulator, sino el sistema operativo real ejecutándose sobre 
una DAL (capa de abstracción de dispositivos). Se usa más como herramienta para 
validar los posibles errores y compatibilidad de las aplicaciones en dispositivos PDA 
que tengan esta versión del sistema. 


Puede decirse que los objetivos de la simulación de sistemas operativos son: 
e entender el funcionamiento interno de un SO 
e determinación de cargas de trabajo del SO en un procesador especifico 
(SimOS) 
e diseño de nuevas arquitecturas de sistemas operativos 
e migración de sistemas operativos 


e desarrollo de sistemas operativos basado en componentes, de forma que 
puedan probarse nuevos kernels, servidores, manejadores, cargadores, etc. 


3. Simulación de un sistema operativo mínimo 


Se decidió hacer el intento de codificar un simulador que hiciera las cosas más 
sencillas que un sistema operativo (SO) se supone que realiza. La primera pregunta que 
surgió fue: ¿modelar solo el SO, o se requiere modelar también el hardware donde se 
ejecuta? Este primer problema no es tan sencillo como podría suponerse. Modelar una 
computadora es un ejercicio bastante complejo; y por lo visto hasta el momento un SO 
también es un sistema bastante complejo, como para aumentar la complejidad de la 
implementación. Sin embargo, hay algunos hechos que no pueden dejarse de lado: 


- elsistema operativo se crea para administrar los recursos de una computadora; 


- el SO en la mayoría de los casos es muy dependiente del hardware, pues 
aunque se creen abstracciones de alto nivel para modelar sus servicios, los 
niveles de base siguen encargados de el acceso al hardware y su control; 
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arquitectura de la computadora. 


Esto deja claro que es necesario modelar el hardware para tener una simulación 
completa [5]. 


3.1 El hardware: URM 


Así, se decidió retomar un modelo de computadora llamado URM (Unlimited 
Register Machine). Puesto que este modelo es un procesador abstracto, y tiene muy 
pocas instrucciones, es un ejemplo de dimensiones controlables (haber elegido un 
microprocesador como un Pentium o un PowerPC, seria tema de otro trabajo). La 
URM tiene un numero infinito de registros (R1,R2,R3...) cada uno de los cuales 
contiene en todo momento un numero natural. El contenido de los registros puede ser 
alterado por la URM en respuesta a ciertas instrucciones que puede reconocer. Estas 
instrucciones corresponden a operaciones simples usadas para realizar cálculos con 
números. Una lista finita de instrucciones constituye un programa. Las instrucciones 
son las siguientes: 


e  Z(m). Instrucción cero. Cambia el contenido del registro Rn a cero, dejando sin 
alteración a los demás registros. 


e  S(n). Instrucción sucesora. Incrementa el valor del número contenido en Rn en 1, 
dejando a los otros registros sin alteración. 


e  T(m,n). Instrucción de transferencia. Reemplaza el contenido del registro Rn por el 
valor contenido en Rm. 


e J(m,n,q). Instrucción de salto. El contenido de los registros Rm y Rn son 
comparados; si rm=rn la URM procede a la instrucción q-ésima del programa en 
ejecución; si rm<>rn la URM procede a la siguiente instrucción. 


En la implementación original del simulador de la máquina URM, la idea era darle a 
la máquina un programa escrito con las instrucciones del modelo, y que este las 
ejecutara. Retomar este simulador con el fin de simular un sistema operativo mínimo 
(SOM) requiere de nuevas consideraciones y varios cambios. La consideración 
principal debe ser el separar los componentes de hardware y software del modelo. 
Además en la implementación original: 


e la carga de los programas, la hacia el simulador, y no había explícitamente en el 
modelo un cargador de programas. 


e la URM no constaba con hardware adicional (periféricos); solo la unidad de 
procesamiento, sus registros y la memoria de programa. 


Si se considera que la URM es un procesador, es posible usarla bajo el modelo de 
Von Neumann, y con ello modelar el hardware de una computadora que lo use. Por lo 
tanto, el sistema mínimo requeriría de un procesador, sus registros y memoria 
principal. Las instrucciones del modelo y su implementación conformarían el conjunto 
de instrucciones del procesador, y nos podemos dar el lujo de implementar una 
pequeña ALU para las cuestiones de operaciones aritméticas. Además puede incluirse 
parte del funcionamiento del modelo Von Neuman, agregando un ciclo de fetch y uno 
de ejecución al ciclo de instrucción de la máquina. Estas inclusiones requieren de 
agregar al modelo original dos registros especiales para estos fines. El registro de 
instrucción (IR) y el contador de programa (PC). 


La URM incorpora a su funcionamiento un número ilimitado de registros, pero en 
procesadores reales, estos registros son limitados (acumuladores, registros de 
segmento, de pila, de código, etc.) por lo que debe respetarse esta funcionalidad, 
aunque ajustándola a un numero de registros variable y finito, lo cual permitirá variar 
la configuración del modelo. En cuanto a la memoria, esta puede modelarse como un 
arreglo, donde cada celda de memoria puede contener una instrucción y sus 
parámetros. Por tanto, el acceso a la memoria es de forma lineal, donde el índice del 
arreglo es equivalente a una dirección (celda) de memoria. Este acceso, implica la 
lectura y escritura de datos en memoria. Aunque no forman parte explícitamente del 
modelo, se requerirá implementar un par de instrucciones para estos fines (p.ej. 
READ/WRITE, GET/SET, IN/out, LOAD ax,dir/LOAD dir,ax, etc.) 


3.2 El software: SOM 


En lo que respecta al software, en específico al sistema operativo de esta máquina, 
hay dos alternativas: codificar el sistema operativo en código del modelo simulado o 
crear un módulo que se encargue de las funciones propias del sistema operativo. Como 
se mencionó al principio, lo que se quiere es un sistema operativo mínimo, pero... ¿qué 
es eso? En concreto, es una pieza de software que permita cargar un programa a la 
memoria del modelo y que el procesador lo ejecute. Si tomáramos la primera opción, 
lo primero que salta a la vista es que como el modelo solo consta de 4 instrucciones, el 
conjunto de instrucciones tendría que ser ampliado para permitir el acceso al disco, 
controlar dispositivos, mostrar resultados en un dispositivo de salida, etc. Aunque 
puede hacerse, el modelo se convertiría en un nuevo procesador, y en ese caso sería 
mejor emular un procesador con las instrucciones suficientes como para implementar 
un SO completo. El segundo enfoque es igualmente válido, pues si el mismo 
simulador implementa el modelado de las funciones de nuestro SO mínimo, el 
resultado de la simulación es el mismo. Esta opción es la que se ha implementado. 
Tomar esta decisión implica algunas consideraciones extra, como: 


e Que la dirección de carga de programas, será el inicio del arreglo que se use. Esto 
se interpretaría como que el SO ya está cargado en memoria, y esa área está 
protegida contra el acceso de otros programas. 


e Que el SO implemente funciones de acceso a dispositivos, aunque estos no formen 
parte explicita del modelo. La entrada/salida estándar es equivalente a que el 
simulador cuente con un monitor. 
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lotes (batch), para lo que se debe incluir un JCL (Job Control Language). El modelo 
solo ejecutará un programa a la vez, por lo que la administración de procesos no fue 
implementada. Además con la simplificación del acceso a memoria tampoco se 
necesita un administrador de memoria, aunque pudiera ser útil si se quisiera expandir la 
memoria base del modelo. El SOM está compuesto de las clases (fig. 1): 


e Loader, se encarga de cargar los programas desde su archivos a la memoria para su 
ejecución. 


e  JCLInterpreter, se encarga de interpretar los comandos JCL. 


e Monitor, está compuesta por Loader y JCLInterpreter y se encarga de cargar un 
programa o un conjunto de programas en memoria para luego ejecutarlos, en base 
a una secuencia de comandos JCL. 


Sistema operativo 





Fig. 1. Diseño de clases del simulados SOM 


4. Resultados 


La estrategia para la construcción del modelo de simulación consistió en modelar los 
principales servicios de administración de los sistemas operativos (procesos, memoria 
y dispositivos), para después integrarlos en diferentes configuraciones, esperando que 
la tarea de integración arroje problemas y consideraciones que aporten soluciones y 
experiencias interesantes para la comprensión del diseño e implementación del 
simulador. Aunque al principio se había planteado solo codificar los algoritmos y 


módulos que son importantes para los sistemas basados en núcleos modulares (los más 
difundidos actualmente), la simulación de cada una de estas partes, y del hardware 
relacionado a su funcionamiento, ha dado como resultados algunas configuraciones 
similares a los primeros sistemas (sencillos pero muy ilustrativos). Los principales 
resultados de este primer experimento son: 


1. El escoger el modelo de URM para la simulación, no permite experimentar con 
programas que tengan un control total sobre los recursos. Para este fin, el conjunto 
de instrucciones debería ser lo más real posible, aunque para los fines de este 
trabajo, conviene que tenga el menor numero de elementos posibles. 


2. El conjunto de instrucciones de la URM es suficiente para crear programas útiles, 
sin embargo, habría que agregar instrucciones adicionales para el control de 
registros, accesos a memoria y recursos, etc.; por eso es que los conjuntos de 
instrucciones de los procesadores reales tienen tantas instrucciones. 


3. Implementar la abstracción de dispositivos de E/S reduce la complejidad, pues 
modelar dispositivos específicos, como tarjetas de red, etc. hace necesario contar 
con más elementos teórico-prácticos. 


4. Para reforzar el modelo de simulación, es recomendable (sino indispensable) 
permitir que el usuario de la herramienta pueda visualizar el comportamiento del 
modelo, e incluso modificar su comportamiento, en cualquier momento. 


5. Conclusiones 


El enfoque de simulación ha sido usado ya en 2 cursos de sistemas operativos en la 
Fundación Arturo Rosenblueth con muy buenos resultados, pues los estudiantes han 
tenido la oportunidad de explorar el interior de este tipo de sistemas, y a partir de ahí, 
ellos mismos han hecho sus propios simuladores. Además este enfoque permite a los 
desarrolladores probar nuevos subsistemas del SO antes de una implementación en 
forma, lo cual reduce los costos considerablemente. 
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